REMARKS 

Claims 1-14, 17, 20-50, and 62-71 are pending and stand rejected. New claims 72-73 are 
added herein. Support for the new claims is found throughout the specification, including at 
paragraphs 64 and 150. 

35 U.S.C. § 103 Rejections 

Claims 1-2, 17, 27, 36-41, 49-50, 63-65, and 67-71 stand rejected under 35 U.S.C. § 
103(a) as being unpatentable over Beringer et al. (Pub. No. US 2004/0205765 Al) in view of 
Kasi et al. (Pat. No. US 7,340,508 Bl). Claims 3-9 and 35 stand rejected under § 103(a) as being 
unpatentable over Beringer in view of Kasi and Saga Software, Inc. (WO 00/29924). Claims 20- 
26, 28-34, 42-48, 62, and 66 stand rejected under § 103(a) as being unpatentable over Beringer in 
view of Kasi and Thilmany et al. (BizTalk®: Implement Design Patterns for Business Rules with 
Orchestration Designer, Oct. 2001, MSDN® Magazine). Claims 10-12 and 14 stand rejected 
under § 103(a) as being unpatentable over Beringer in view of Kasi and Moore et al. (Pub. No. 
US 2004/0034848 Al). Claim 13 stands rejected under § 103(a) as being unpatentable over 
Beringer in view of Kasi, Moore and further in view of Lee et al. (The Extensible Rule Markup 
Language, May 2003, ACM). Applicants respectfully traverse these rejections and discuss them 
together for clarity. 

Claim 1 recites a method of creating an application for executing on at least one machine 
having a memory. The method comprises creating a definition of a node and a specification, 
both of which are held in at least one machine readable data file and written in a markup 
language. The claim recites that the specification is arranged to be processed by a run time 
environment and defines: 
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i: how the at least one node interacts with other nodes during the 

processing of the specification; 
ii: resources useable by the at least one node during the processing of the 

specification; 

iii: at least one set of predetermined rules used by the at least one node 

during the processing of the specification; and 
iv: a set of messages which are arranged to be passed between nodes 

during the processing of the specification. 

Beringer does not disclose these four aspects. 

Referring to the description of Web Services Description Language (WSDL) at 
http://www.w3.org/TR/2007/REC-wsdl20-20070626/, it can be seen in the Introduction that 
WSDL 2.0 provides a model and an XML format for describing Web services. WSDL 2.0 
enables one to separate the description of the abstract functionality offered by a service from 
concrete details of a service description such as "how" and "where" that functionality is offered. 
"This specification defines a language for describing the abstract functionality of a service as 
well as a framework for describing the concrete details of a service description. It also defines 
the conformance criteria for documents in this language." 

Thus, WSDL is a format that defines the capabilities/requirements of the document 
receiver. It does not provide any information about the document sender, or indeed any other 
node that the receiver node could interact with and exchange further messages. This relationship 
is clearly reinforced by Figure 1 of Beringer which shows the WSDL document 18 as being an 
intermediate of the Service Provider 12 and the Service Requestor 14; it is published by the 
Service Provider 12 in order that Service Requestors 14 that wish to communicate with it can do 
so. Figure 1 also shows that the Service Provider 12 has a Schema 34 therewithin, which 
(referring to paragraph 18 of Beringer) "defines or specifies the messaging features to be used in 
messages between the Service Provider and Service Requestor". The Schema is a different 
document to the WSDL document. 
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The BizTalk Messaging Framework is a proprietary product provided by Microsoft. 

Referring to http://www.microsoft.com/biztalk/en/us/overview.aspx is can be seen that: 

BizTalk Server is Microsoft's Integration and connectivity server solution. 
A mature product on its sixth release, BizTalk Server 2009 provides a solution 
that allows organizations to more easily connect disparate systems. Including over 
25 multi-platform adapters and a robust messaging infrastructure, BizTalk Server 
provides connectivity between core systems both inside and outside your 
organization. In addition to integration functionality, BizTalk also provides strong 
durable messaging, a rules engine, EDI connectivity, Business Activity 
Monitoring (BAM), RFID capabilities and IBM Host/Mainframe connectivity. 

The Examiner refers to paragraph 4 of Beringer to show that Beringer teaches "the specification 

defining how the at least one node interacts with other nodes during processing of the 

specification" (Interaction Clause). The BizTalk Framework referenced in paragraph 4 is a 

Microsoft Standard and has nothing to do with either the Schema or the WSDL document shown 

in Figure 1 of Beringer. 

Thus, Beringer does not show a specification indicating how one node interacts with 
other nodes. In support of the rejection of the Interaction Clause, the Examiner also makes 
reference to the Schema (first line of paragraph 18), which makes reference to the BizTalk 
Framework. Paragraph 18 of Beringer also refers to the Schema 34 as shown in Figure 1. As 
such it is referring to the capability of the Service Provider. 

In addition, WSDL makes a definition about the Service Provider 12. Therefore it 
specifies the possible message exchanges of the Service Provider (i.e. Node) with which other 
nodes must comply. This is NOT what claim 1 of the present application requires. The present 
claim recites that the specification specify how The Node (i.e. the Service Provider) interacts 
with other nodes during processing and thus limits what any one node that is defined can do. The 
Service Requestor of Beringer is not a Node within the sense of the current application. 
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In support of the rejection of "The specification defining resources useable by the at least 
one node during processing of the specification" (Resources Clause) the Examiner relies upon 
paragraphs 26 and 34 of Beringer which relate to the WSDL document 18. This is not the 
BizTalk Framework that the Examiner used to show the Interaction Clause. Thus, already the 
Examiner is using two distinct aspects of Beringer (i.e. the Schema - which references an 
external Framework and the WSDL document) to show what is required to be within a single 
specification by the current claim. The distinctness of these two aspects of Beringer is 
highlighted by Beringer' s Figure 1 which shows them as being separated and it will be apparent 
from the discussion above about WSDL that the function of the WSDL document is in no way 
related to the Schema. Paragraph 26 of Beringer which the Examiner uses to show the Resources 
Clause again refers to the schema 34 of Figure 1. Again therefore, this paragraph refers to the 
capability of the Service Provider. 

Further, Beringer fails to disclose a 'Specification that defines at least one set of 
predetermined rules used by the at least one node during the processing of the specification" 
(Rules Clause). Paragraphs 41 and 42 show extracts of the WSDL document and the Examiner is 
apparently referring to the portion of code: "<xsd:documentation>Provides a rule on how to 
construct the string for the topic field using XSL </xsd:documentation>" to teach the Rules 
Clause. Again, the WSDL document is not the Schema and not the BizTalk framework on which 
the Examiner initially relied. Instead, this phrase is part of the data structure <xsd:complexType 
name = "topicRuleType"> and as such defines a data structure for a specific data field expected 
to be received in a message. It does not define a set of rules which are later used to process data 
when implemented in the run time environment. The Examiner has cherry picked the phrase 
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'rule' with no indication of the requirement of the later parts of the claim which further define 
that rule. 

Even if the Examiner's arguments could be accepted, it is noted that the resultant rule 
would make a call to an XSL transformation. This XSL transformation is a further document 
outside of the specification. As a result Beringer teaches to use a Schema, a WSDL definition, a 
BizTalk framework and to call XSL transformations. This is not processing of the specification 
in a run time environment to provide a memory resident node which processes data by the at 
least one memory resident node as is claimed. 

Paragraph 41 of Beringer which the Examiner uses to teach the Rules Clause relates to 
the capabilities of the Service Provider since it is discussing the Schema 34. Hence, it does not 
disclose or suggest the Rules Clause in the manner claimed. 

There is a fourth requirement of the specification - that it defines "a set of messages 
which are arranged to be passed between nodes" (Messages Clause). Paragraph 17 of Beringer 
which the Examiner uses to teach the Messages Clause relates to the capabilities of the Service 
Requestor since it relates to the WSDL document. 

Thus, the four clauses of Beringer on which the Examiner relies not only do not show a 
specification that provides all of the definitions but they do not together specify a node; three of 
the references relate to one of the nodes of Beringer whereas the fourth reference relates to the 
other node. The nodes in Beringer have a different functionality and as such, the Examiner will 
appreciate that the definition of the required node is not met. 

From the above, it is clear that the Examiner has failed to show Beringer has a single 
specification containing the four clauses (Interaction, Resources, Rules and Messages) which can 
later be processed to provide the functionality of the application. Instead, the Examiner has relied 
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upon two documents (the Schema and WSDL documents together with the BizTalk framework) 
to highlight features which are different from those required by the present claim. Thus, a 
combination of Beringer and Kasi does not show all of the features required by the claim and as 
such cannot render the claim obvious. 

There are also further limitations to the Examiner's analysis. In particular, the Examiner 
has split the clause "process, according to rules defined in the specification for that node data 
provided to the at least one memory resident node by messages such that rules are triggered if 
predetermined data is present within a message" in two rather than reading it together and 
subsequently cherry picked disparate features from Beringer to show two different clauses 
compared to what should be unified teaching. 

The Examiner takes the first portion "process, according to rules defined in the 
specification for that node" and argues that paragraph 19 of Beringer teaches this because it can 
determine whether messages comply with the WSDL interface. That is the Examiner is arguing 
that processing of a message to determine whether it complies with a WSDL interface teaches 
what is claimed. 

The Examiner then takes the second portion "data provided to the at least one memory 
resident node by messages such that rules are triggered if predetermined data is present within a 
message" and argues that the INVOKE process as shown in Figure 1 teaches this aspect. The 
Examiner then refers to paragraph 52 which relates to a Schema and NOT the WSDL document 
or the BizTalk Framework to which he has previously referred. Paragraph 76 on which the 
Examiner also relies discusses that messages must comply with a format as specified in the rules. 
Paragraph 76 in no way suggests rules which are triggered if predetermined data is present 
within a message; Beringer discloses parsing the message format and does not disclose 
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processing the message contents. It is the processing of data by performing business logic and 
arithmetic contained within the message that is significant and not simply processing of the 
message to determine whether it is in the correct format. 

Thus, even though the Examiner has tried to change the meaning of the clause by 
splitting it inappropriately, the Examiner has still failed to show the Beringer processes data 
according to a set of rules which have previously been provided in a specification. The Examiner 
in fact relied on rules which are defined in disparate portions of Beringer and which format 
messages rather than process them. 

Further, the Examiner relies upon paragraph 80 of Beringer to teach the clause of the 
current claim "output further messages dependent upon triggering of rules". It is not clear how 
the phrase "An attachment extension in accordance with schema 46 may be specified in 
predefined locations in the WSDL document" can teach outputting of a further message upon 
triggering of a rule. 

Finally, the Examiner fails to point out where the clause "wherein links between nodes 
are dynamically configured responsive to amendments to the specification during processing 
thereof by the run time environment" is found in either Beringer or Kasi. Thus, the rejection of 
claim 1 is prima facie deficient. Even if this last clause were found in the references, a person of 
ordinary skill in the art at the time the invention was made would not find the claimed invention 
obvious for the reasons provided above. 

Referring to claim 1 1, the Examiner believes that this is obvious in view of a combination 
of Beringer, Kasi and Moore. At best Beringer teaches a skilled person that rules can be used to 
ensure that messages follow a predetermined format as specified in a schema. What Beringer 
does not teach (and what is discussed at length above) is to process data within a message 
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according to a rule; i.e. the format of the rule does not matter but it is the data within the message 
that is important. This is a fundamental shift and as such it would not be obvious to a skilled 
person to restructure Beringer in order to replace the schema with the rule engine of Moore. As 
such, Applicants submit that claim 1 1 is not obvious in view of the combination of references. 

The other independent claims are not obvious for at least the same reasons as claim 1 . In 
addition, the other references cited by the Examiner do not remedy the deficiencies of Beringer 
described above, nor does the Examiner allege that they do. Therefore, Applicants request that 
the Examiner withdraw the rejections. 

CONCLUSION 

Applicants respectfully submit that the pending claims are patentable over the cited art 

and request that the Examiner withdraw the rejections and allow the claims. The Examiner is 

invited to contact the undersigned to advance the prosecution of this case. 

Respectfully submitted, 

Dated: November 18, 2009 By: /Brian Hoffman/ 

Brian M. Hoffman, Reg. No. 39,713 

Attorney of Record 

Fenwick & West LLP 

801 California Street 

Mountain View, CA 94041 

Tel.: (415)875-2484 

Fax: (415)281-1350 
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